UN-3479 [FIX] Stamp adapter_key alongside adapter_id_key on tool_instance PATCH#1995
Conversation
…ance PATCH ToolInstanceHelper.update_metadata_with_adapter_properties resolved the adapter and only wrote the target UUID to metadata[adapter_id_key], leaving metadata[adapter_key] as whatever the PATCH sent (a name from to_representation, or a stale UUID from create() defaults). The schema enum is on adapter_key, and the lazy migrator skips any UUID-shaped value there — so stale UUIDs survive PATCH and later fail validation with "<source-or-deleted-uuid> is not one of [<target-uuid>]" during workflow execution (seen on cloned org workflows after adapter churn). Write the resolved UUID to both keys so the invariant metadata[adapter_key] == metadata[adapter_id_key] == <current org UUID> holds after every save. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughThe ChangesAdapter Instance Metadata
🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Test ResultsSummary
Runner Tests - Full Report
SDK1 Tests - Full Report
|
|
| Filename | Overview |
|---|---|
| backend/tool_instance_v2/tool_instance_helper.py | Fixes missing write to metadata[adapter_key] in update_metadata_with_adapter_properties; deduplicates metadata_key_for_id lookup across if/else branches; no regressions found. |
Sequence Diagram
sequenceDiagram
participant UI
participant Serializer
participant update_metadata_with_adapter_properties
participant DB as AdapterInstance DB
UI->>Serializer: PATCH tool_instance (adapter name or UUID)
Serializer->>update_metadata_with_adapter_properties: "metadata[adapter_key] = name OR stale UUID"
alt adapter_value is UUID format
update_metadata_with_adapter_properties->>DB: "AdapterInstance.objects.get(id=adapter_value)"
DB-->>update_metadata_with_adapter_properties: adapter object
else adapter_value is a name
update_metadata_with_adapter_properties->>DB: get_adapter_by_name_and_type(name)
DB-->>update_metadata_with_adapter_properties: adapter object
end
Note over update_metadata_with_adapter_properties: adapter_id = str(adapter.id)
update_metadata_with_adapter_properties->>update_metadata_with_adapter_properties: "metadata[adapter_key] = adapter_id (NEW - fix)"
update_metadata_with_adapter_properties->>update_metadata_with_adapter_properties: "metadata[adapter_id_key] = adapter_id (existed before)"
Note over update_metadata_with_adapter_properties: Both keys now hold the canonical UUID
Reviews (1): Last reviewed commit: "UN-3479 [FIX] Stamp adapter_key alongsid..." | Re-trigger Greptile



Summary
ToolInstanceHelper.update_metadata_with_adapter_propertiesresolved the adapter on PATCH but only wrote the target UUID tometadata[adapter_id_key], leavingmetadata[adapter_key]carrying whatever the PATCH sent — a name fromto_representation, or a stale UUID fromcreate()defaults / a prior clone iteration's deleted adapter.adapter_key, andensure_adapter_ids_in_metadatashort-circuits the lazy NAME→UUID migration whenever it sees any UUID-shaped value there. So a stale UUID atadapter_keysurvives PATCH and later trips workflow execution with:metadata[adapter_key]andmetadata[adapter_id_key]so the invariantmetadata[adapter_key] == metadata[adapter_id_key] == <current org UUID>holds after every save. Existing affected rows self-heal on the next PATCH (UI re-save, or rerun of the org-clone tool_instance phase).metadata_key_for_idlookup that existed in both branches.Test plan
is not one oferror).metadata[adapter_key]matchesmetadata[adapter_id_key].🤖 Generated with Claude Code